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Description 

[0001] This invention concerns a method for generat- 
ing a software application that can be applied to several 
different target platforms according to claim 1 , a device 5 
for generating a software application that can be applied 
to several different target platforms according to claim 
11, a program module containing a software application 
according to claim 12 and a data processing unit con- 
trolled by a software application according to claim 13. w 
[0002] Software is created by means of a develop- 
ment process. Such a design method for deriving soft- 
ware from a user model is described in the European 
Patent Application EP 0 540 .487. 

[0003] Normally, application software is generated *5 
and encoded closely related to the respective target 
platform, on top of which this application will later be ex- 
ecuted. The programmer has to take into account the 
application programming interface (API) of the target 
platform and he has to choose the platform dependent 20 
means and functional principles to implement the exe- 
cution principles of his application. He has therefore for 
example to consider the mechanisms of the operation 
systems (UNIX, Windows NT, ...) of the target platform. 
[0004] This approach has the disadvantage, that the 25 
description of the application produced by the program- 
mer is dependent on the respective platform and can 
therefore not be automatically be transformed to anoth- 
er target platform. If the application has to be executed 
on another platform, a totally new description of the ap- 30 
plication has to be encoded by the programmer. 
[0005] Another drawback of this approach is, that the 
programmer requires knowledge of the platform specif- 
ics, which he cannot reuse when he has to encode pro- 
grams for other target platforms. 35 
[0006] Further, there already exist some standards 
and products (OMG/CORBA, ... ) that allow an object 
oriented, platform independent design of application 
software. These standards and tools are mainly used 
for generating software applications that are of higher 40 
complexity, which is for example the case in the tele- 
communications field. In such a object oriented design 
description of an application the functions of the appli- 
cation are described by a plurality of interaction objects. 
If the application is realized with a CORBA product 45 
(CORBA = Common Object Request Broker Architec- 
ture), the specification of the interaction between ob- 
jects is done by means of the IDL language. This de- 
scription is translated to source code written in a pro- 
gramming language, which allows to ensure distribution so 
transparency at the programming level. 
[0007] But other platform implementation aspects 
have still to be managed by the programmer. Therefore, 
the drawbacks mentioned for the above approach still 
exists. 55 
[0008] As described above it is necessary for realizing 
an application on an platform to pass through a whole 
software design process. The problem is to reduce de- 



velopment efforts for realizing application for multiple 
platforms. 

[0009] Accordingly, it is a primary objective of the 
present invention to de-couple in the software design 
process an application from the underlying target plat- 
form at the design but also at the programming level. 
This de-coupling is done by introducing a a computa- 
tional description for the structure and semantic of said 
application and an engineering description for the im- 
plementation principles in terms of encapsulation and 
resource allocation of said application, both in a platform 
independent way. This de-coupling is followed by real- 
izing or programming both descriptions, independently. 
[0010] De-coupling the engineering steps in such a 
way allows to divide implementation complexity by fo- 
cusing an application implementor via providing the re- 
spective (platform independent) framework. The inte- 
gration of these descriptions is uniform with respect to 
an arbitrary platform, thus could be made mechanical 
which reduces the portation effort. 
[0011] This objective is solved by a method for gen- 
erating a software application that can be applied to sev- 
eral different target platforms according to the teaching 
of claim 1 , a device for generating a software application 
that can be applied for several different target platforms 
according to the teaching of claim 11 , a program module 
implementing a software application according to the 
teaching of claim 12 and a data processing unit control- 
led by a software application according to the teaching 
of claim 13. 

[001 2] The underlying idea, this invention is based on, 
is to separate the "what has to be done" from the "how 
it has to be done" and describe these two thing's plat- 
form independently in two separated descriptions, a 
computational description and an engineering descrip- 
tion. These two descriptions are then used to map the 
application onto the respective target platform. 
[001 3] This new approach has following advantages: 

• It ensures the portability of application architecture 
and of the application code. 

The programmer does not have to take care on the 
API of the target platform. 

• it is possible to reconfigure an application without 
change the application code. By separation of the 
configuration aspects, that are part of the engineer- 
ing description, from the objects and interfaces de- 
scriptions and code, that are part of the computa- 
tional description, flexibility is gained and you be 
able to change the configuration without having to 
change the objects and interfaces descriptions and 
code. 

[0014] Therefore, by using this new approach the de- 
velopment and evolution costs of an application and 
time to market of an application are reduced. 
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[0015] Other advantageous embodiments of the in- 
vention are described in the subclaims. 
[001 6] It's especially advantageous to integrate char- 
acteristics into the computational and in the engineering 
description 5 

• to ensure a good mapping and the use of the most 
adapted mechanisms of the target platform and 

• to answer the needs set by the technological field 
of the application, for example to answer telecom- 
munication application needs. 

[0017] The characteristics added in both separated 
descriptions have an implementation on the target plat- 
form. The characteristics in the descriptions that re- 
quires the knowledge of the platform for the mapping 
and execution are taken into account by generation 
tools and an executive support. This executive support 
takes care of ensuring satisfaction of the characteristics 
and the user does not need to know the platform spe- 
cifics. 

[0018] The present invention will now be described 
with reference to the accompanying drawings, wherein 

Fig. 1 is a block diagram presenting the architecture 
of a program module according to the invention. 

Fig. 2 is an illustration presenting a part of an engi- 
neering description. 

Fig. 3 illustrates a flowchart presenting the process- 
ing of a method for generation of a software appli- 
cation according to the invention. 

[0019] Fig. 1 shows a software architecture model 
with an application level L1 , a support level L2 and a 
platform level L3. 

[0020] The application level L1 contains two different, 
separated description, a computational description CD 
and an engineering description ED. With these both de- 
scriptions the application is described in a platform in- 
dependent way. 

[0021] The platform level contains a target platform 
TP. This target platform has a platform specific applica- 
tion programming interface. The support level L2 maps 
the application described by the computational descrip- 
tion CD and the engineering description ED on the target 
platform TP. The support level L2 hides the target plat- 
form specifics and manages ist resources, like distribu- 
tion, communication, threads.. . 
[0022] It is possible that this mapping is supported by 
tools associated to the support level L2. 
[0023] Therefore, a program module implementing an 
application has the following architecture: 
[0024] The program module contains the computa- 
tional description CD and the engineering description 
ED, that describe the application in a platform independ- 
ent way. Further it contains software modules of the sup- 



port level, that provide the mapping of these two descrip- 
tions onto the target platform TP. If the application 
should be transformed to another target platform, only 
these software modules have to be changed. 
[0025] In a preferable embodiment of the invention 
these software modules of the support level are gener- 
ated from the two descriptions ED and CD and from a 
respective target platform profile. This is an efficient way 
to generate a well-adapted support level L2. 
[0026] In the following an embodiment of the invention 
is described in more detail: 

[0027] The computational description CD holds the 
abstract notions necessary to describe the structure and 
the semantics of an application in terms that are not di- 
rectly bound to a particular technology. 
[0028] In a preferable embodiment the descriptions 
CD and ED are based on an object model. An object 
model embodies the ideas of modularity and data en- 
capsulation that are useful for structuring and reusability 
purposes. 

[0029] For creating the computational description CD, 
the object has to be abstracted from the direct platform 
issues. A collection of object classes and the relation 
between them has to be described. As example for the 
objects described in the computational description two 
objects OB1 and OB1 are shown in Fig. 1. 
[0030] Objects are described platform independently 
in two different description's ways: An interaction view 
description IVD and a design view description DVD. 
[0031] The interaction view description IVD describes 
the interface of an object with the rest of the application, 
that is what service it offers to the rest of the application. 
The interaction view description IVD of an object inter- 
face contains: 

the definition of supporting types for defining oper- 
ations 

• the signature of each operation that can be invoked 
by clients of an interface of that type 

[0032] The interaction view description IVD follows 
the RPC model (RPC=Remote Procedure Call). The 
type of interactions is part of the specification of each 
operation. Two basic types of interactions are support- 
ed: interrogation or notification. If more application re- 
quirement has to be taken into account additional inter- 
action types can be introduced. 
[0033] As language for describing the object interac- 
tion view description IVD a language IDL is used. This 
language IDL is for example the CORBA/IDL language 
or a subset of the CORBA/IDL language. 
[0034] The design view description DVD defines the 
internal layout of the object, that is, the information that 
guides both the implementors of the functional encoding 
and the support software for the support level L2. 
[0035] In the design view description DVD the focus 
is on the object definition and on its internal structure. 
This includes the interface that the object provides to 
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the outside world. 

[0036] In this description it's advantageous to assign 
to an object class one or more non-functional charac- 
teristics that are relevant to its implementation. Such 
characteristics can be: 5 

interfaces from other objects that are used, 

• supported interfaces, 

• administrative interfaces to manage the object life- 
cycle 10 

• execution profile including concurrence and behav- 
ioral characteristics (a execution profile is a prede- 
fined model of execution whose properties are well 
known), 

• quality of service constraints * 5 

• data persistency. 

[0037] If the description of such non-functional and 
quality of service properties is sufficiently rich and ac- 
curate, the choice of an execution profile can be auto- 20 
mated. Having only a limited set of execution profiles 
allows to master the complexity of the platform program- 
ming and to ensure the efficiency of the object imple- 
mentation. 

[0038] As language for describing the design view de- 25 
scription DVD a language ODL is used. As language 
ODL an expand version of the existing language ODLV 
CORBA (ODL=Object Description Language) can be 
used, that contain additional syntax for assigning the 
above mentioned characteristics. 30 
[0039] To finish the description of an object class, the 
programmer has to code or describe the operations of 
the object class. This is preferably be done after the de- 
sign view description D1 and the interaction view de- 
scription D2 are fully described. By doing this, the com- 35 
putational description CD for the objects OB1 and OB2 
is finished. 

[0040] The characteristics of an object class are en- 
sured by the support level L2. Therefore, the program- 
mer has not take them into account. He has for example *o 
not to care about thread management. He can concen- 
trate on the interactions with the other objects (instance 
creation , operation invocation and instance destruc- 
tion). 

[0041] The engineering description ED addresses the 45 
describing of the implementation principles of the appli- 
cation. These information's are necessary towards the 
concretization of the computational abstract notions that 
has to be initiated on the target platform. 
[0042] Whereas the computational description CD fo- so 
cus on individual object design issues, the engineering 
description ED addresses architectural issues and in 
particular "how" the "what" will be done. The application 
is now viewed as a collection of object instances. The 
engineering description describes for example issues of 55 
placement (what will be local, what will be remoted) or 
grouping of service instances into units of execution re- 
source allocation (that will be later mapped to platform 



concepts such as processes). 

[0043] Following main notions are used to describe 

the engineering description: 

• A capsule is an abstraction of a resource provision 
unit. Object instances are grouped into capsules. 
Characteristics are assigned to a capsule that de- 
scribe its behavior. These characteristics are for ex- 
ample the assignment of engineering threads and 
queues'. 

• A node represents the entity that actually provides 
physical execution resources, it refers to a single 
computer or station 

Recovery: in case the application is not able to pur- 
sue its computation because there is for example a 
system or an applicative problem, parameters are 
assigned that initiating the recovery of a part of it. 
The smallest unit of recovery is a capsule. 

• An object instance can be statically or dynamically 
created activated deactivated and destroyed 
through a factory service. 

[0044] Figure 2 shows an example of a part of such 
an engineering description. It shows 3 capsules C1 to 
C3, containing object instances Ol. The object instances 
Ol are distributed into the capsules C1 to C3 and each 
of the capsules C1 to C3 are dimensioned according to 
the implementation principles of the application. 
[0045] The capsule C1 is assigned to the handling of 
a call. It contains several different interaction object in- 
stances directed to signaling, charging, call managing 
and CNX managing. The capsules C2 and C3 contains 
several subscriber object instances. 
[0046] Further, according to implementation princi- 
ples of the application the above mentioned character- 
istics and parameters are assigned to the capsules C1 
to C3 and an assignment is specified that map the cap- 
sules C1 to C3 to the available nodes. 
[0047] The engineering description ED is described 
by means of a configuration description language CDL. 
[0048] The applicative objects that have been de- 
scribed by the computational description CD are 
mapped onto the target platform TP. Both descriptions, 
the computational description CD and the engineering 
description ED are used to choose the most suitable 
mechanisms of the target platform. There is not only an 
intermediate layer, the support layer L2, put on top of 
the platform, but this intermediate layer is generated 
from the two descriptions CD, ED in such a way, that the 
best advantage's for its regarding application character- 
istics is taken. The use of platform functionality and inner 
mechanisms of the platform are completely controlled 
by the support level L2. 

[0049] Advantageous, the translation from the com- 
putational description CD and the engineering descrip- 
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tion ED to the platform programming interface of the tar- 
get platform TP is done at software production time and 
not at runtime. This is done by using a respective target 
platform profile well suited to the target platform TP. 
[0050] Because of the complete description of the se- 
mantic, structure and implementation principles, map- 
ping rules can be precisely defined for every target plat- 
form and can be stored in a target platform profile. 
[0051] The support level comprising a generic runtime 
GM, a plurality of object support modules OS1 and OS2 
and a capsule support module CS. 
[0052] The object support modules OS 1 and OS2 and 
the capsule support module CS make the link between 
the two descriptions of ED and CD and the generic runt- 
ime GM. 

[0053] The object support modules OS1 and OS2 are 
generated from the computational description CD. The 
support modules OS1 and OS2 take care, that the char- 
acteristics of the object class are respected and imple- 
mented on the target platform TP. 
[0054] The capsule support module CS is generated 
from the engineering description ED. It takes care on 
the implementation principles and makes the mapping 
of these implementation principles on platform concepts 
like processes and software components and to gener- 
ate automatically the respective services. 
[0055] The generic runtime GM is independent from 
the application. It includes operations like communica- 
tion, the thread management It uses the target plat- 
form specificities to manage the distribution, the plat- 
form resources, the communications between object in- 
stances, the recovery, ... 

[0056] The runtime GM implements the execution 
k profiles specified in the design description of the objects. 
It includes the instance concurrence control, the thread 
management inside a capsule and the choice of internal 
communication mechanisms. Further, the runtime GM 
makes the interfaces with the platform, the management 
of the instances life-cycle, the management of the data 
persistency and of the recovery of active instances in 
case of crash failure. 

[0057] The generation of a platform independent ap- 
plication is now demonstrated according to Fig. 3. 
[0058] Fig. 3 shows 4 application description steps D 1 
to D4, 3 compilation steps COMP1 to COMP3, the sup- 
port modules CS, OS1 and OS2 and two mapping pro- 
files MP1 and MP2. 

[0059] In the description steps D1 and D2 the design 
view description DVD and interaction view description 
IVD of the objects of the application are inputted and 
memorized. 

[0060] In the description step D3 the engineering de- 
scription ED is inputted and memorized. 
[0061] The memorized design view description DVD 
and interaction view description IVD of the objects of the 
application are translated, after performing consistency 
checks, in the compilation step COMP1 into a program- 
ming language. In the description step D4 a description 



of the operations of the objects is inputted. This descrip- 
tion is written in said programming language and filled 
in the position determined by the translated design view 
description DVD and interaction view description IVD of 
5 the objects. This detail computational description CD is 
then memorized. 

[0062] In the compilation step COMP2 the engineer- 
ing description ED is translated, after performing con- 
sistency checks, into the support module CS that con- 

10 tain alt material required to build up the application: 
source files, make files or equivalent. 
[0063] In the compilation step COMP3 the computa- 
tional description CD is translated into the support mod- 
ules OS1 and OS2. This compilation steps takes into 

is account the mapping profiles MP1 and MP2. The map- 
ping profile MP1 is the runtime GM and the mapping pro- 
file MP2 are the target platform liberies. 

20 Claims 

1 . A method for generating a software application that 
can be applied to several different target platforms, 
said method comprising the steps of determining a 

25 primary user goal, deriving a sub-goal structure, 
conceptual specification, functional specification, 
and implementation, characterized by comprising 
the further steps of de-coupling said application into 
a computational description (CD) describing the 

30 structure and semantic of said application in a plat- 
form independent way and an engineering descrip- 
tion (ED) describing the implementation principles 
in terms of encapsulation and resource allocation 
of said application in a platform independent way, 

35 implementing the engineering description (ED) in a 
platform independent way, implementing the com- 
putational description (CD) in a platform independ- 
ent way, and mapping the application onto one of 
said several target platforms (TP) by means of a re- 

40 spective target platform profile and of both of said 
two separated descriptions (CD, ED). 

2. The method according to claim 1 , characterized by 
further including the step of memorizing the compu- 

45 tational description (CD) and the engineering de- 
scription (ED) based on abstract notions. 

3. The method according to claim 1 , characterized by 
further including the step of memorizing the engi- 

50 neering description (ED) as a description of inter- 
acting objects. 

4. The method according to claim 1 , characterized by 
further including the steps of memorizing of one or 

55 several non-functional characteristics in the compu- 
tational description (CD) and using that character- 
istics for the mapping and the selection of the best 
adapted mechanisms of said target platform (TP). 
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5. The method according to the claims 3 and 4, char- 
acterized by further including the step of memoriz- 
ing a description (DVD) of a plurality of said inter- 
acting object respectively assigned one or several 
of said non-functional characteristics describing the 
non-functional behavior of the respective interact- 
ing object. 

6. The method according to claim 1 , characterized by 
further including the steps of memorizing of one or 
several characteristics in the engineering descrip- 
tion (ED) and using said characteristics for the map- 
ping and the use of the best adapted mechanisms 
of said target platform (TP). 

7. The method according to the claims 3 and 6, char- 
acterized by further including the step of memoriz- 
ing a description of grouping of instances of said 
interacting objects (Ol) and a description of an as- 
signment between a group of object instances (C1 
to C3) and a specific group characteristic. 

8. The method according to claim 1 , characterized by 
further including the step of generating one or sev- 
eral executive support modules (OS1 , OS2, CS) out 
of the computational description (CD) and the engi- 
neering description (ED), which controls the execu- 
tion of the application together with a (generic) runt- 
ime (GS) implementing platform independent runt- 
ime parts. 

9. The method according to claim 8, characterized by 
further including the step of generating separated 
executive support modules (OS1, OS2; CS) out of 
the computational description (CD) and the engi- 
neering description (ED), respectively, which link 
the computational description (CD) and the engi- 
neering description (ED) with the generic runtime 
(GS), respectively. 

10. The method according to the claims 4, 6 and 8, 
characterized by further including the step of gen- 
erating the executive support modules (OS1, OS2,. 
CS) in such a way that the executive support mod- 
ules (OS1, OS2, CS) selects by means of the ge- 
neric runtime (GS) proper mechanisms of the target 
platform (TP) to satisfy the characteristics of the ap- 
plication described in the computational description 
(CD) and in the engineering description (ED). 

11. A device for generating a software application that 
can be applied to several different target platforms, 
said device, characterized by containing first input- 
ting means for inputting a computational description 
(CD) describing the structure and semantic of said 
application in a platform independent way, second 
inputting means for inputting an engineering de- 
scription (ED) describing the implementation princi- 



ples of said application in a platform independent 
way, programming means for programming the en- 
gineering description (ED) in a platform independ- 
ent way, programming means for programming the 

s computational description (CD) in a platform inde- 
pendent way, memory means for memorizing said 
computational description and said engineering de- 
scription as two separated, platform independent 
descriptions of said application, and generating 

10 means for generating by means of both of said two 
separated descriptions (CD, ED) and of a target 
platform profile an executive support (OS1, OS2, 
CS, GS) that maps the application onto a respective 
one of said several target platforms (TP). 

15 

12. A program module implementing a software appli- 
cation, said program module containing two sepa- 
rated, platform independent descriptions of said ap- 
plication, a computational description (CD) describ- 

20 ing the structure and semantic of said application in 
a platform independent way and a engineering de- 
scription (ED) describing the implementation princi- 
ples of said application in a platform independent 
way, and containing mapping means (OS1, OS2, 

25 CS, GS) for mapping the application described by 
said two separated descriptions (CD, ED) onto a 
target platform (TP). 

13. A data processing unit controlled by a software ap- 
30 plication, said data processing unit containing two 

separated, platform independent descriptions of 
said application, a computational description (CD) 
describing the structure and semantic of said appli- 
cation in a platform independent way and a engi- 

35 neering description (ED) describing the implemen- 
tation principles of said application in a platform in- 
dependent way, and containing mapping means 
(OS1, OS2, CS, GS) for mapping the application 
described by said two separated descriptions (CD, 

40 ED) onto a target platform (TP). 



Patentanspruche 

45 1. Verfahren zur Erzeugung eines zum Ablauf auf 
mehreren unterschiedlichen Zielplattformen geeig- 
neten Software-Anwendungsprogramms, wobei 
das Verfahren die Schritte der Festlegung eines pri- 
maren Benutzerziels, Ableitung einer Unterziel- 

so Struktur, Aufgabenstellung, Funktionsbeschrei- 
bung und Implementierung umfasst, dadurch ge- 
kennzeichnet, dass es folgende weitere Schritte 
umfasst: Trennen des Anwendungsprogramms in 
eine Rechenbeschreibung (CD), welche die Struk- 

55 tur und Semantik des Anwendungsprogramms in 
plattformunabhangiger Weise beschreibt, und eine 
Realisierungsbeschreibung (ED), welche die Im- 
plementierungsprinzipien in Bezug auf Verkapse- 
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lung und Ressourcenzuteilung des Anwendungs- 
programms in plattformunabhangiger Weise be- 
schreibt; plattformunabhangige Implementierung 
des Realisierungsprogramms (ED); plattformunab- 
hangige Implementierung der Rechenbeschrei- 
bung (CD); und Abbildung des Anwendungspro- 
gramms auf eine der mehrere Zielplattformen (TP) 
mittels eines jeweiligen Zielplattform profits und bei- 
der der beiden getrennten Beschreibungen (CD, 
ED). 

2. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dass es als weiteren Schritt die Speiche- 
rung der Rechenbeschreibung (CD) und der Reali- 
sierungsbeschreibung (ED) auf der Grundlage von 
abstrakten Begriffen umfasst. 

3. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dass es als weiteren Schritt die Speiche- 
rung der Realisierungsbeschreibung (ED) als eine 
Beschreibung von interagierenden Objekten um- 
fasst. 

4. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dass es folgende weitere Schritte um- 
fasst: Speicherung eines nicht funktionellen Merk- 
mals oder mehrerer nicht funktioneller Merkmale in 
der Rechenbeschreibung (CD); und Verwendung 
des Merkmals oder der Merkmale fur die Abbildung 
und die Auswahl der am besten geeigneten Mecha- 
nismen der Zielplattform (TP). 

5. Verfahren nach den AnsprQchen 3 und 4, dadurch 
gekennzeichnet, dass es als weiteren Schritt die 
Speicherung einer Beschreibung einer Vielzahl von 
interagierenden Objekten enthalt, denen jeweils ei- 
nes oder mehrere der nicht funktionellen, das nicht 
funktionelle Verhalten des jeweiligen Objekts be- 
schreibenden Merkmale zugeordnet ist. 

6. Verfahren nach Anspruch 1, dadurch gekenn- 
zeichnet, dass es folgende weitere Schritte ent- 
halt: Speicherung eines oder mehrerer Merkmale in 
der Realisierungsbeschreibung (ED); und Verwen- 
dung dieser Merkmale fur die Abbildung und die 
Auswahl der am besten geeigneten Mechanismen 
der Zielplattform (TP). 

7. Verfahren nach den AnsprQchen 3 und 6, dadurch 
gekennzeichnet, dass es als weiteren Schritt die 
Speicherung einer Beschreibung einer Gruppie- 
rung von Instanzen der interagierenden Objekte 
(Ol) und eine Beschreibung einer Zuordnung zwi- 
schen einer Gruppe von Objektinstanzen (C1 bis 
C3) und einer spezifischen Gruppeneigenschaft 
umfasst. 
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zeichnet, dass es als weiteren Schritt die Erzeu- 
gung eines oder mehrerer AblaufunterstOtzungs- 
Module (OS1, OS2, CS) aus der Rechenbeschrei- 
bung (CD) und der Realisierungsbeschreibung 
(ED) umfasst, welche die Ausfuhrung des Anwen- 
dungsprogramms zusammen mit einer (generi- 
schen) AusfOhrungszeit (GS) steuern, die plattfor- 
munabhangige Teile der AusfOhrungszeit imple- 
mentiert. 



9. Verfahren nach Anspruch 8, dadurch gekenn- 
zeichnet, dass es als weiteren Schritt die Erzeu- 
gung getrennter AusfuhrungsunterstOtzungs-Mo- 
dule (OS1 , OS2; CS) aus der Rechenbeschreibung 

15 (CD) beziehungsweise der Realisierungsbeschrei- 
bung (ED) umfasst, welche die Rechenbeschrei- 
bung (CD) beziehungsweise die Realisierungsbe- 
schreibung (ED) mit der generischen AusfOhrungs- 
zeit (GS) verknOpfen. 

20 

10. Verfahren nach den AnsprQchen 4, 6 und 8, da- 
durch gekennzeichnet, dass es folgenden weite- 
ren Schritt umfasst: Erzeugung der Ablaufunterstut- 
zungs-Module (OS1, OS2, CS) in der Weise, dass 

25 die Ablaufunterstutzungs-Module (OS1, OS2, CS) 
mittels der generischen Ablaufzeit (GS) geeignete 
Mechanismen der Zielplattform (TP) zur Erfuilung 
der Merkmale des in der Rechenbeschreibung (CD) 
und der Realisierungsbeschreibung (ED) beschrie- 

30 benen Anwendungsprogramms auswahlen. 

11. Einrichtung zur Erzeugung eines zum Ablauf auf 
mehreren unterschiedlichen Zielplattformen geeig- 
neten Software-Anwendungsprogramms, dadurch 

35 gekennzeichnet, dass sie enthait: erste Eingabe- 
mittel zur Eingabe einer Rechenbeschreibung 
(CD), welche die Struktur und Semantik des An- 
wendungsprogramms in plattformunabhSngiger 
Weise beschreibt; zweite Eingabemittel zur Einga- 

40 be einer Realisierungsbeschreibung (ED), welche 
die Implementierungsprinzipien der Anwendungs- 
programms in plattformunabhangiger Weise be- 
schreibt; Programmiermittel zur plattformunabhan- 
gigen Programmierung der Realisierungsbeschrei- 

45 bung (ED); Programmiermittel zur plattformunab- 
hSngigen Programmierung der Rechnenbeschrei- 
bung (CD); Speichermittel zum Abspeichern der 
Rechenbeschreibung und der Realisierungsbe- 
schreibung als zwei getrennte, plattformunabhan- 

50 gjge Beschreibungen des Anwendungspro- 
gramms; und Erzeugungsmittel zur Erzeugung ei- 
nes das Anwendungsprogramm auf jeweils eine der 
mehreren Zielplattformen (TP) abbildenden Aus- 
fuhrungsunterstOtzungs-Moduls (OS1, OS2, CS, 

55 GS) mittels beider der beiden getrennten Beschrei- 
bungen (CD, ED) und eines Zielplattformprofils. 



8. Verfahren nach Anspruch 1, dadurch gekenn- 12. Programmmodul, das ein Software-Anwendungs- 
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programm implementiert, enthaltend: zwei getrenn- 
te, plattformunabhSnige Beschreibungen des An- 
wendungsprogramms, namlich eine Rechenbe- 
schreibung (CD), welche die Struktur und Semantik 
des Anwendungsprogramms in plattformunabhan- 
giger Weise beschreibt, und eine Realisierungsbe- 
schreibung (ED), welche die Implementierungs- 
prinzipien des Anwendungsprogramms in plattfor- 
munabhSngiger Weise beschreibt; und Abbildungs- 
mittel (OS1 , OS2, CS, GS) zur Abbildung des durch 
die beiden getrennten Beschreibungen (CD, ED) 
beschriebenen Anwendungsprogramms auf eine 
Zielplattform (TP). 

13. Datenverarbeitungseinheit, die von einem Soft- 
ware-Anwendungsprogramm gesteuert wird, ent- 
hattend: zwei getrennte, plattformunabhSngige Be- 
schreibungen des Anwendungsprogramms, nSm- 
lich eine Rechenbeschreibung (CD), welche die 
Struktur und Semantik des Anwendungspro- 
gramms in plattformunabhangiger Weise be- 
schreibt, und eine Realisierungsbeschreibung 
(ED), welche die Implementierungsprinzipien des 
Anwendungsprogramms in plattformunabhangiger 
Weise beschreibt; und Abbildungsmittel (OS1, 
OS2, CS, GS) zur Abbildung des durch die beiden 
getrennten Beschreibungen (CD, ED) beschriebe- 
nen Anwendungsprogramms auf eine Zielplattform 
(TP). 



Revendications 

1. Procede pour generer une application de logiciel 
qui peut etre applique a differentes plateformes ci- 
bles, ledit procede comprenant Tetape de determi- 
nation d'un but utilisateur primaire, de derivation 
d'une structure de sous-but, de specification con- 
ceptuelle, de specification fonctionnelle et mise en 
oeuvre, caracterise en ce qu'il comprend les eta- 
pes supplementaires de decouplage de la dite ap- 
plication en une description informatique (CD) de- 
crivant la structure et la semantique de ladite appli- 
cation d'une maniere independante de la platefor- 
me et une description technique (ED) decrivant les 
principes de mise en oeuvre en termes decapsu- 
lation et d'attribution de ressources de ladite appli- 
cation d'une maniere independante de la platefor- 
me, mettant en oeuvre la description technique 
(ED) d'une maniere independante de la plateforme, 
mettant en oeuvre fa description informatique (CD) 
d'une maniere independante de la plateforme et 
configurant ^application sur Tune desdites plusieurs 
plateformes cibles (TP) a I'aide d'un profil de plate- 
forme cible respectif et des deux dites descriptions 
separees (CD, ED). 

2. Procede selon la revendication 1 , caracterise en 



ce qu'il comprend, en outre, Tetape de memorisa- 
tion de la description informatique (CD) et de la des- 
cription technique (ED) sur la base de notions abs- 
traites. 

5 

3. Procede selon la revendication 1 , caracterise en 
ce qu'il comprend, en outre, Tetape de memorisa- 
tion de la description technique (ED) comme une 
description d'objets interactifs. 

10 

4. Procede selon la revendication 1, caracterise en 
ce qu'il comprend, en outre, les etapes de memo- 
risation d'une ou plusieurs caracteristiques non 
fonctionnelles dans la description informatique 

15 (CD) et d'utilisation de ces caracteristiques pour la 
configuration et la selection des mecanismes les 
mieux adaptes de ladite plateforme cible (TP). 

5. Procede selon les revendications 3 et 4, caracteri- 
20 se en ce qu'il comprend, en outre, Tetape de me- 
morisation d'une description (DVD) d'une pluralite 
desdits objets interactifs auxquels sont respective- 
ment affectees une ou plusieurs desdites caracte- 
ristiques non fonctionnelles decrivant le comporte- 

25 ment non fonctionnel dudit objet interactif respectif. 

6. Procede selon la revendication 1 , caracterise en 
ce qu'il comprend, en outre, les etapes de memo- 
risation d'une ou plusieurs caracteristiques dans la 

30 description technique (ED) et d'utilisation desdites 
caracteristiques pour la configuration et Tutilisation 
des mecanismes les mieux adaptes de ladite plate- 
forme cible (TP). 

35 7. Procede selon les revendications 3 et 6, caracteri- 
se en ce qu'il comprend, en outre, Tetape de me- 
morisation d'une description de regroupement 
distances desdits objets interactifs (Ol) et une 
description d'une affectation entre un groupe d'ins- 

40 tances (C1 a C3) et une caracteristique de groupe 
specifique. 

8. Procede selon la revendication 1 , caracterise en 
ce qu'il comprend, en outre, Tetape de generation 

45 d'un ou plusieurs modules supervisees de support 
(OS1, OS2, CS) a partir de la description informa- 
tique (CD) et de la description technique (ED), qui 
commande Texecution de Tapplication conjointe- 
ment avec une version d'execution (generique) 

so (GS) mettant en oeuvre des parties de version 
d'execution independantes de la plateforme. 

9. Procede selon la revendication 8, caracterise en 
ce qu'il comprend, en outre, Tetape de generation 

55 de modules superviseursde support separes(OS1, 
OS2; CS) a partir de la description informatique 
(CD) et de la description technique (ED), respecti- 
vement, qui lient la description informatique (CD) et 
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la description technique (ED), respectivement, 
avec la version d'execution generique (GS). 

10. Precede selon les revendications 4, 6 et 8, carac- 
terise en ce qu'il comprend, en outre, i'etape de 
generation des modules supervisees de support 
(OS1, OS2, CS) de telle maniere que les modules 
supervisees de support (OS1 , OS2, CS) selection- 
nent, a I'aide de la version d'execution generique 
(GS) t des mecanismes propres de la plateforme ci- 
ble (TP) pour repondre aux caracteristiques de i'ap- 
plication decrite dans la description informatique 
(CD) et dans la description technique (ED), 

11. Dispositif pour generer une application de logiciel 
qui peut Stre applique a differentes plateformes ci- 
bles, ledit dispositif, caracterise en ce qu'il com- 
prend un premier moyen de saisie pour saisir une 
description informatique (CD) decrivant la structure 
et la semantique de ladite application d'une maniere 
independante de la plateforme, un second moyen 
de saisie pour saisir une description technique (ED) 
decrivant les principes de mise en oeuvre de ladite 
application d'une maniere independante de la pla- 
teforme, un moyen de programmation pour pro- 
grammer la description technique (ED) d'une ma- 
niere independante de la plateforme, un moyen de 
programmation pour programmer la description in- 
formatique (CD) d'une maniere independante de la 
plateforme, un moyen de memorisation pour me- 
moriser ladite description informatique et ladite des- 
cription technique comme deux descriptions sepa- 
rees, independantes de la plateforme, et un moyen 
de generation pour generer, a I'aide des deux dites 
descriptions separees (CD, ED) et d'un profil de pla- 

' teforme cible, un support superviseur (OS1, OS2, 
CS, GS) qui configure Papplication sur une platefor- 
me respective desdites plusieurs plateformes ci- 
bles (TP). 

12. Module de programmes mettant en oeuvre une ap- 
plication de logiciel, ledit module de programmes 
comprenant deux descriptions separees, indepen- 
dantes de la plateforme, de ladite application, une^ 
description informatique (CD) decrivant la structure 
et la semantique de ladite application d'une maniere 
independante de la plateforme et une description 
technique (ED) decrivant les principes de mise en 
oeuvre de ladite application d'une maniere indepen- 
dante de la plateforme et comprenant un moyen de 
configuration (OS1, OS2, CS, GS) pour configurer 
('application decrite par ies deux dites descriptions 
separees (CD, ED) sur une plateforme cible (TP). 

1 3. Unite informatique commandee par une application 
de logiciel, ladite unite informatique comprenant 
deux descriptions separees, independantes de la 
plateforme, de ladite application, une description in- 



formatique (CD) decrivant la structure et la seman- 
tique de ladite application d'une maniere indepen- 
dante de la plateforme et une description technique 
(ED) decrivant les principes de mise en oeuvre de 
5 ladite application d'une maniere independante de 
la plateforme et comprenant un moyen de configu- 
ration (OS1, OS2, CS, GS) pour configurer ('appli- 
cation decrite par les deux dites descriptions sepa- 
rees (CD, ED) sur une plateforme cible (TP). 

10 



15 



20 



25 



30 



35 



40 



45 



50 



9 



EP 0 860 773 B1 




EP 0 860 773 B1 




11 



EP 0 860 773 B1 




12 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



L3 BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




